In telecommunications networks, a user of an originating communication device may wish to conduct a communication session such as a Voice over Internet Protocol (VoIP) call with the user of another communication device. In order to set up such a communication session, a request, such as a Session Initiation Protocol (SIP) Invite request, will be transmitted from an originating communication device to a network device such as a SIP server which is responsible for routing the request to the appropriate destination.
A request will contain an identifier for a destination for the request, for example a hostname (such as ‘metaswitch.com’). To work out where to send such requests, the SIP protocol stipulates (for example in Internet Engineering Task Force (IETF) Request for Comments (RFCs) 3261 and 3263) that one or more destination address lookups should be performed by the SIP element that is responsible for routing the request. A destination address lookup may for example comprise transmitting a Domain Name System (DNS) query to a DNS server responsible for providing a DNS lookup service in the telecommunications network. Such destination address lookups resolve a hostname or other identifier to a set of destination addresses to try.
Assuming a destination address lookup for a request returns at least one destination address, the request is routed to that destination address. If the given destination address replies with a specific special type of response (for example a SIP 503 Service Unavailable message), or does not reply at all for a given time period (for example a 32 second time-out period), the SIP server should try the next destination address provided by the destination address lookup. If the SIP server cannot find any responsive destination address after working its way through all the destination addresses provided by the destination address lookup service, a failure response is returned to the originating communication device.
In the case where there is no response from several destination addresses, it can take a long time (many multiples of 32 seconds) for the SIP server to work through those destinations addresses. The caller operating the originating communication device will typically have given up (and cancelled the call) before more than two destinations have been tried. The SIP server will stop DNS processing at that point. It soon becomes unacceptable for a service provider and their customers if this affects a lot of calls because callers will just hear silence for many seconds after attempting to conduct calls.
For this reason, it is known to “blacklist” any destination address found to be unresponsive, often for several minutes. A SIP element will ignore blacklisted destinations when performing DNS procedures. This means that fewer calls to problematic destinations are likely to suffer from long-term silence.
An example of such a problematic call is depicted in FIG. 1. Here the user of a requesting device 108 initiates a call via their requesting device 108. A call request is transmitted to SIP server 100 in step 1a. The call request includes an identifier for the desired destination, in this case the hostname ‘metaswitch.com’. A DNS lookup is performed for this hostname in step 1b and destination addresses A, B and C are returned to SIP server 100 in step 1c. SIP server 100 transmits a request to destination address A in step 1d. No response is received from destination address A and the request times-out in step 1e. Destination address A is blacklisted and a further request is transmitted to destination address B in step 1f. While waiting for a response from destination address B, the call is cancelled by the user of requesting device 108 in step 1g. No response is received from destination address B and the request times-out in step 1h. Destination address B is blacklisted. The call has been cancelled, so destination address C is not attempted for that call.
The user of requesting device 108 (or a different requesting device, say requesting device 107) initiates another call via their requesting device 108 so a second call request is transmitted to SIP server 100 in step 1i. The second call request includes an identifier for the same desired destination, i.e. hostname ‘metaswitch.com’. A DNS lookup is performed for the identifier in step 1j and destination addresses A, B and C are returned to SIP server 100 in step 1k. Destination address A and destination address B are blacklisted, so a request is transmitted to destination address C in step 1l. Destination address C responds in step 1m and the call succeeds. In the above example, although the first call attempt failed, subsequent call attempts to the same hostname now succeed quickly. If destination addresses A and B had not been blacklisted, the second call would have suffered the same fate as the first.
Blacklisting is beneficial for a further reason. In the context of hundreds of call attempts per second, to different destinations which might correspond to partially overlapping sets of destination addresses, a SIP server can reduce the time spent trying non-responsive destinations. An example of such a problematic call is depicted in FIG. 2. Here the user of a requesting device 108 initiates a call via their requesting device 108 and a call request is transmitted to SIP server 100 in step 2a. The call request includes an identifier for the desired destination, in this case the hostname ‘metaswitch.com’. A DNS lookup is performed for this hostname in step 2b and destination addresses A and B are returned to SIP server 100 in step 2c. SIP server 100 transmits a request to destination address A in step 2d. No response is received from destination address A and the request times-out in step 2e. Destination address A is blacklisted and a further request is transmitted to destination address B in step 2f. 
Meanwhile, the user of the same or a different requesting device 108 initiates a further call and a further call request is transmitted to SIP server 100 in step 2g. The call request includes an identifier for the desired destination, in this case to a different hostname ‘dataconection.com’. A DNS lookup is performed for this hostname in step 2h and destination addresses A and C are returned to SIP server 100 in step 2i. Destination address A is blacklisted so a request is transmitted to destination address C in step 2k. Destination address C responds in step 2l and the call succeeds. In this example, a potentially failed call attempt was avoided by not attempting to route a request to destination address A, because SIP server 100 knew that destination address A was unresponsive, even though the further call was destined for a hostname different from the hostname of the initial call.
A problem arises if all of the destination addresses for a destination which the SIP server responsible for routing requests receives are blacklisted. Requests sent to such an affected destination would be rejected immediately until at least one entry in the blacklist had been timed-out; this could take some time. It would therefore be desirable to provide improved ways of processing requests in a telecommunications network, including where blacklisting of destination addresses is implemented.